Use linearly increasing ramp as inflow BC #620
Conversation
| @@ -17,7 +17,7 @@ stopAt endTime; | |||
|
|
|||
| endTime 5; | |||
|
|
|||
| deltaT 0.01; | |||
There was a problem hiding this comment.
Using a ramp also allows us to use a larger time step size in OpenFOAM. I did not change the overall time window size in the precice-config.xml since I am not sure if we will see the same effect in nutils. And I'm also not sure if there is any potential for increasing the time step size in SU2.
Would be helpful and a useful step in the scope of this PR if anybody wants to evaluate this but also not necessary, since preCICE generally supports using a smaller time step size in the config than in the solver (if everything is implemented correctly in the adapters).
There was a problem hiding this comment.
Hey Benjamin, sorry this was on my feed and I just thought I would put a quick comment. Hope you well otherwise :).
I have also encountered issues with inflow conditions (back when I was still building CFD codes). Esp, for incompressible solvers and large velocities (its basically water hammer). What I found, which worked really well, was to use a sigmoid function as the ramp, as the gradients are nicer. You have 'no' discontinuity at the start or end, so the 'size/magnitude' of the final velocity does not affect the size of the jump over the starting discontinuity (time step dependent though) and it 'gives' the flow some time to react locally. When I talk of discontinuity here its a C1 discontinuity.
Anyways just my 2 cents comment.
There was a problem hiding this comment.
Hi @bevanwsjones, thank you for the comment and the hint with the sigmoid function! That's very helpful. If we are already touching the case it would be nice to directly use a solution that works well (even for higher-order).
I also had some trouble with C1 discontinuous inflow velocities when I tried to reach 2nd order in time for the results presented here. The fix I found was using a -cos(t)+1 instead of a sin(t) as inflow condition for the elastic-tube-1d example. I assume this is a similar case and time-stepping order should also profit from higher-order continuity here.
|
I'm done with my work on this PR. Nutils is still a todo and if somebody with more experience in nutils could contribute this part this would be helpful. There is also a possible performance gain if we increase the overall time step size. But this needs careful evaluation and we could also do this as a follow up. |
|
Don't forget to update the |
|
Side remark: In the QNWI paper, we used a Stokes solution as initial guess in Nutils to circumvent the continuity problem (required to reach higher order in time): https://gitlab.lrz.de/precice/ijnme2019-experiments/-/blob/master/Fluid-Structure%20Interaction/convergence/run-wi/Nutils/nsale.py?ref_type=heads#L173-176 |
Use a linearly ramp as initial condition: The inflow velocity starts for$$t=0$$ at $$u_x=0$$ and linearly increases to $$u_x=10$$ at $$t=1$$ . For $$t>1$$ we use a constant inflow velocity of $$u_x=10$$ .
Todos:
Checklist:
changelog-entries/<PRnumber>.md.